*854*At one end of the executable graphics spectrum are diagrammatic programming systems—progeny of the early flowcharts*383* used by assembly-language programmers. Flow-diagram sketches have long been used to describe the flow of control in program structure. But the ultimate goal for a diagram-based programming system is to make these charts, graphs, and diagrams executable—like all program code. There has been only relative success in meeting this goal.
Several systems incorporate a set of flowchart-like symbols as a graphical extension to a text-based programming language.6 The symbols by themselves are generally not interpretable. They must be annotated with text to be visually meaningful, and they must be translated into a traditional language before they can be executed.
The developer enters a program using an interactive graphical interface. The system then generates the graphical representation of the program and a translation of it into a traditional text-based language. The translation is then submitted to the system for program execution.
Dataflow diagrams *237*describe the flow of data in the program structure. They are used in conjunction with dataflow languages. In a dataflow system, a dataflow language *240*is directly translated into a dataflow diagram. Programming does not follow from a flowchart diagram of the program and a translation of it into an executable language, as is found in other diagrammatic systems.
The dataflow diagram itself is the program. It is made up of graphs*399*, with nodes representing functions and arcs representing data dependencies*224* between functions. Dataflow programming is discussed in greater detail later in this chapter.
State-transition diagrams *1005*describe both the flow of control and the interactive user-interface at key points in the program structure. Like a dataflow diagram, state transition diagrams consist of nodes and arcs. But here, the nodes represent states and the directed arcs (showing the direction of flow from node to node) represent state transitions. There are paths from node to node in the diagram showing the flow of an operation or action. An operation or action occurs when the user interacts with the system and follows the path describing the operation.
 
Prograph’s dataflow diagrams are directly executable program code.
Most diagrammatic systems are graphical extensions to textual programming languages. Visual expressions are used mainly to make the structure of the program clear—the diagrams themselves are not executable. Because its dataflow diagrams are directly executable code, Prograph is an excellent example of a fully diagrammatic programming language—the language is in the pictures.
Table-based and Form-based Systems
*1062*Table-based and form-based programming*385* systems capitalize on a user’s daily experience of handling data in spreadsheets and forms. Both of these programming systems aim at nonprogramming professionals who must collect, enter, retrieve, and update information, usually in a series of operations within a relational database. The user already visualizes data in terms of tables or forms, so the programming language mimics these operations used in working with a table or in filling out a form.
In a table-based system *870*the user begins with a two-dimensional skeleton table.7 The table is then defined by means of user queries to the system requesting choices available for specifying each table component, such as column headings, data attributes, and so on. The user then enters data into the fully specified table and stores it as a base table in the database. Each base table can then be accessed for developing new tables using the same query method.
In form-based visual programming systems,*856* the goal is to design and develop a relational database on the basis of forms for collecting data.8 Forms are defined using a form-based programming language.
The actual layout of the form—invoice, purchase order, expense report, and so on—is specified using a screen editor. The fields are defined—field type, input or update action, and so on—and the form is stored in the forms database. The database user can then request access to a particular form and fill in the fields using database queries in a query language such as SQL.*995*
Icon-based Systems
Iconic programming systems *857*can truly be called visual programming. In contrast to *873*text-based*1079**1076* systems, icon-based systems use pictures as programming-language constructs, that is, executable graphics. Unlike most diagrammatic systems, these pictures are the code, not graphics to be translated into text before execution. And unlike table-based and form-based systems, iconic programming is not limited by an underlying database perspective.
In an icon-based system*427*, programming is done with pictures. The pictures take advantage of intuitive pattern-recognition mental processes. These fully visual elements do not require that the user be linguistically adept. Such a system is universal; no matter what the native language, the user is not limited by language syntax.
Although these advantages are impressive, developing an icon-based system that meets such expectations is not easy. Just providing picture-based programming code is not enough. *858*A good icon-based system must be clear and meaningful, not too simple yet not too complex. Icons should portray objects and concepts clearly and not be confusing or hard to remember. Each icon should be uniquely identifiable but not so complex that it becomes incomprehensible. There should not be too many icons, nor too few.
Having too many icons requires a dictionary, and iconic*426* dictionaries can be time-consuming and difficult to use. Having too few icons leaves many concepts and objects unspecifiable—requiring a text-based language to enhance the graphical elements of the programming system. In short, good iconic-based programming systems are difficult to design.9
Interest in icon-based programming is not new, but the *859*speed and memory requirements for running such systems have previously restricted iconic programming to the level of research curiosity without commercial potential. This is no longer true.
The cost of graphics-related hardware and software has continued to drop over the past few years. And the speed and memory requirements of an iconic programming system can now be met on today’s desktop computer. Picture-based programming systems are today commercially viable microcomputer products.
 
Prograph icons are unique, yet easily remembered.
Computer-industry analysts increasingly see a good graphical*402* language as the Esperanto of computer programming—an international programming language, immediately accessible and instantly usable by any programmer, no matter what his or her linguistic background or verbal capability.
And for business computing, there is no question about the productivity and efficiency issues involved in having an easy-to-use programming language available to nonprofessional programmers. The issue today revolves around finding a visual language that offers the greatest flexibility for a range of different programming requirements.
How Visual Is Prograph?
*882*Prograph is a fully visual development environment, as well as a fully specified icon-based language.
There are multiple windows for viewing program execution states, visual editors for specifying classes and methods, and both executable dataflow diagrams and executable icons in the windows themselves. Even the debugging facilities have been given a fully visual and editable design.
All criteria for a well-designed icon-based programming system are met. Prograph’s language icons are clear, simple, and easily remembered. They are unique, yet not confusing. There are not too many icons, nor too few. Prograph is an icon-based language for real-world application development.
Prograph also provides the full range of features found in both dataflow programming systems and in object-oriented programming languages. In the next section you examine Prograph from its object-oriented programming foundation.
